Fix AddDependency no-op when libs.versions.toml is present on Gradle 9#7550
Open
Fix AddDependency no-op when libs.versions.toml is present on Gradle 9#7550
Conversation
The `withToolingApi` test helper was mutating `projectDir` to the
`gradle/` subdirectory whenever it saw a `gradle/libs.versions.toml`
source file. On Gradle 8.x the `-b` flag still pointed the daemon at
the real build script, masking the bug; on Gradle 9.x the flag was
removed and the daemon evaluated the wrong directory, returning a
GradleProject whose `nameToConfiguration` was empty. AddDependency
then silently no-opped because `getConfiguration("compileOnly")`
returned null.
- Drop the projectDir mutation: `gradle/libs.versions.toml` is a
catalog inside the existing project, not a project-root marker.
- AddDependencyVisitor now emits a `Markup.warn` listing available
configurations instead of silently swallowing unknown-configuration
cases, so future shape mismatches surface.
- Add AddDependencyGradle9CatalogTest covering Gradle 9.0.0 and 8.14.3
with the catalog present.
Fixes #7548
OpenRewrite's MavenPomDownloader was getting an HTTP 404 for lombok 1.18.44 in CI, even though the artifact exists. Use a long-stable version to avoid transient resolution flakes.
CI runners are intermittently getting HTTP 404 from Maven Central for stable artifacts (also affects main). Pass version=null so AddDependency does not invoke MavenPomDownloader. The bug under test is about the recipe making no change at all when libs.versions.toml is present on Gradle 9, so the dependency version is incidental.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
withToolingApitest helper was mutatingprojectDirto thegradle/subdirectory whenever agradle/libs.versions.tomlsource file was provided; on Gradle 8.x the-bflag masked the bug, but on Gradle 9.x (which dropped-b) the daemon evaluated the wrong directory, returned aGradleProjectwith emptynameToConfiguration, andAddDependencysilently no-opped. The mutation is removed,AddDependencyVisitornow emits aMarkup.warnlisting available configurations instead of silently swallowing unknown-configuration cases, and a regression test exercises the catalog scenario on both Gradle 9.0.0 and 8.14.3.Test plan
AddDependencyGradle9CatalogTestpasses on Gradle 9.0.0 and Gradle 8.14.3:rewrite-gradle:test(full module sweep) passes